Subject: Prposed Update to TRS Architecture

From: [email-masked] (Matthew Finlayson)
Date: Thu, 06 Oct 94 17:37:12 BST

Tim,

Thanks for your response to our proposal. Our comments follow.

> It's rare that both of these conditions hold true, so for the majority of
> sessions this check is not performed.  When they are true, only the NN
> whose name matches is being checked.  Many, probably most, NNs (especially
> if they are routers) in the network won't be checked with the 8083 fix.  I
> agree that in many cases the tree for this route is already cached.  If
> there are no ENs connected to the local NN that talk to the ENs connected
> to any remote NNs, however, a tree is probably not already cached that
> contains a path between the two NNs.

I don't entirely follow your reasoning here.  The CP-CP session tree will
need to exist (at least) every time a directed locate is sent out (or a
QUERY_CP_NAME is issued if proposal 8083 is accepted).  If a node supports
Option Set 1200 (Tree Caching and TG Caching), then it must build the
entirety of a tree (it may not only build the needed portion of a tree).
This is explained clearly in the Architecture Reference (SC30-3422-3), on
page 7-70.

> Given an origin network node and a COS name, the RSS algorithm constructs
> a tree whose root is the origin node and whose branches contain every
> other topologically reachable network node in the network under the
> constraints of the COS definition, if trees are cached in the
> implementation... If trees are not cached in the implementation, RSS
> stops constructing the tree when all destination nodes have been added to
> the tree.

This means that in any node which supports 1200, the CP-CP session tree
will be present nearly all the time - this means that the overhead involved
in checking the reachibility of a node will be minimal.

Also, the proposed alternate solution will not work in all scenarios.
Although it will work in all the scenarios I listed, it is only effective
when the effect of a TG going down is to isolate a single node.  It does
not take account of a network partition.  For example - consider the
following topology (a modified form of the second example I gave in my
original email).

     NNB---VRN1
      |        \
      |         NNE
      |        / |
     NNC----NNA  |
      |        \ |
      |         NNF
      |        /
     NND---VRN2

All non-VRN links in the above diagram support CP-CP sessions. If the link
between NNC and NND goes down and NND wishes to establish a session to NNB,
the route NND->VRN2->NNF->NNE->VRN1->NNB may be used, even if the node
record for NNA has been marked as inconsistent.

The advantage of the original proposed solution is that it is much more
general and will solve all examples of the problem that we can foresee.

Furthermore, the advantage of a solution based on checking the CP-CP
session mesh is that once implemented in a node, that node will alway
generate valid routes.  The alternate solution requires that all the nodes
in a network are upgraded to support it before it will be fully effective.

We still think, therefore, that the original solution is a better response
to the problem, but that it should possibly be part of Option Set 1200.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================

---

From: Mark Cossack <[email-masked]>
Date: Thu, 6 Oct 1994 15:13:07 -0500 (CDT)

Two problems:

The first area where requiring a CP-CP session spanning tree is harmful.

       Network layout:
       ===============

 <NN1>----------------<NN2>
   |  cpssn=*yes        |
   |                    |
   |                    |
   |SWTPP               |
   |cpssn=*no           |cpssn=*yes
   |                    |
   |                    |
   |                    |
   |     cpssn=*yes     |
 <NN4>-----------------<NN3>
   |
   NN...

If the link between NN3 and NN4 fails for a period of time, that would
cut off NN4 and any other NN on the lower side of the network from the
rest of the network for no good reason during the time period(however
long) before the CP Session can be recovered.

Second problem area:
I am opposed to the whole idea of requiring a CP-CP capable route to be
available when a QUERY_CP_NAME successfully finds a DLU which equals an
NN(CP) in the topology database.  As a matter of fact, it would break
existing customers who today perform some 'manual short hold mode' with
their switched networks.  There are APPN customers today who:
1) initially bring up a CP-CP session spanning tree in order to exchange
topology
2) bring down the CP-CP sessions so that a switched-disconnect function
can occur such that the switched link can disconnect at the DLC level
but still be available for APPN routing purposes
3) use the CP name of NNs as their DLUs so that nothing has to flow over
any CP-CP session in order for the route to be calculated from the local
NNs topology database
4) let the BIND activate the necessary links along the path and only pay
for those switched links for as long as the user session is active

This second area may not be state of the art but it does provide for an
extremely
effective usage of switched facilities where the customer does not pay
for any switched link time that is not used for actual user data.  Let's
find a different solution to the problem.

Mark

---------- Forwarded message begins here ----------

To: aiw-appn-reference
<<@MIT.EDU:[email-masked]>>
Cc: [email-masked]
Subject: Prposed Update to TRS Architecture
From: [email-masked] (Matthew Finlayson)
Date: Thu, 06 Oct 94 17:37:12 BST
Sender: [email-masked]

Tim,

     NNB---VRN1
      |        \
      |         NNE
      |        / |
     NNC----NNA  |
      |        \ |
      |         NNF
      |        /
     NND---VRN2